home *** CD-ROM | disk | FTP | other *** search
/ Collection of Tools & Utilities / Collection of Tools and Utilities.iso / c / tcomm50.zip / LXM.DOC < prev    next >
Text File  |  1988-01-30  |  26KB  |  1,113 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8.  
  9.               INTRODUCING LXM
  10.  
  11.  
  12. BRIEF HISTORY OF XMODEM
  13.  
  14.  
  15. During the glory days of CP/M, the computer industry was
  16. plagued with a plethora of diskette formats. Since there was
  17. no single standard around, particularly when the 5" format
  18. was introduced, data interchange between computers was
  19. difficult.
  20.  
  21.  
  22. Several manufacturers attempted to provide a solution by
  23. giving their users the ability to at least read multiple
  24. diskette formats. Rather than promoting a standard format,
  25. this approach encouraged manufacturers to adopt proprietary
  26. formats as a marketing tool. Partially as a response to this
  27. situation, and partially out of a need to provide data
  28. transmission capabilities, Ward Christiansen developed the
  29. original specification for the XModem file transfer
  30. protocol.
  31.  
  32.  
  33. The XModem protocol, elegant in its simplicity and
  34. effectiveness, has transcended the decline of CP/M-based
  35. systems, and the ascendency of MS-DOS to become a de facto
  36. standard for data transfer between remote computers. This
  37. fact is true, even in the light of the near-universal
  38. acceptance of another de facto standard for diskette
  39. formats, as popularized by the IBM-PC family. With the
  40. advent of the new PS/2 with its incompatible micro-
  41. diskettes, the XModem protocol's place, at least for the
  42. foreseeable future, seems assured.
  43.  
  44.  
  45.  
  46.            PROTOCOL FUNDAMENTALS
  47.  
  48.  
  49. THE TRANSMISSION BLOCK
  50.  
  51.  
  52. The fundamental building block of XModem is an 8-bit byte,
  53. no parity please, arranged into transmission blocks of
  54. exactly 132 characters, never more nor less. In one
  55. extension to XModem, commonly called CRC-XModem, the
  56. transmission blocks are exactly 133 characters. We will
  57. discuss this extension , and a second known as YModem,
  58. later.
  59.  
  60.  
  61.  
  62.  
  63.  
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70.     LXM(tm) - LITECOMM (tm) XMODEM ENGINE for Microsoft
  71.            Datalight and Turbo C
  72.  
  73. As you might guess, not only is the length of a transmission
  74. block fixed, but so too is the format. The XModem block
  75. format looks like this:
  76.  
  77.  
  78.     <SOH> <REC> <~REC> <...128 Data Bytes...> <checksum>
  79.  
  80.  
  81.  
  82. where:
  83.  
  84.      SOH - 0x01 Signals the start of a block
  85.      REC - Is the sequential block number reduced modulo 256
  86.      ~REC - The ones-compliment of REC
  87.      checksum - an 8-bit sum of the preceding 128 data
  88.     bytes, formed by adding each byte to an
  89.     accumulator, then dropping all but the low order 8
  90.     bits of the result.
  91.  
  92.  
  93. The intent of the additional characters is to facilitate
  94. error checking and recovery, making the XModem protocol an
  95. "error-free" means of data transfers under otherwise hostile
  96. conditions.
  97.  
  98.  
  99. The block number and its compliment are included to insure
  100. that no blocks are accidentally lost during transmission,
  101. and to prevent the accidental duplication of a data block
  102. which might be caused by spurious line noise. The checksum
  103. seeks to insure the validity of the actual data which might
  104. become garbled by line noise. The fixed length block format
  105. tends to simplify the logic required to implement the
  106. protocol in the first place.
  107.  
  108.  
  109.  
  110. THE INTER-COMPUTER DIALOG
  111.  
  112.  
  113. Xmodem is essentially uni-directional in nature. That is,
  114. the actual flow of meaningful information occurs in one
  115. direction at a time, from the sending computer to the
  116. receiving computer. This is not meant to imply, however,
  117. that only one computer sends and the computer receives. To
  118. the contrary, there is a constant "dialog" going on between
  119. the two computers during the course of the transmission. It
  120. is this dialog that permits XModem to be true, "error-free"
  121. transfer method.
  122.  
  123.  
  124.  
  125.  
  126.  
  127.    CopyRight (c) 1987, 1988 Information Technology, Ltd.
  128.  
  129.  
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136.     LXM(tm) - LITECOMM (tm) XMODEM ENGINE for Microsoft
  137.            Datalight and Turbo C
  138.  
  139. Xmodem is a receiver-driven protocol. The receiving computer
  140. initiates and almost exclusively controls the transmissions,
  141. through a series of pre-planned responses. A typical, though
  142. brief dialog might look like this:
  143.  
  144.  
  145.      RECEIVER         SENDER           MEANING
  146.  
  147.       <NAK>        -------------->    READY TO RECEIVE
  148.   <-------------    <BLOCK1>    FIRST BLOCK SENT
  149.       <ACK>        -------------->   BLOCK RECEIVED OK
  150.   <-------------    <BLOCK2>     SECOND BLOCK
  151.       <NAK>        -------------->    ERROR, RESEND
  152.   <-------------    <BLOCK2>     SECOND BLOCK
  153.       <ACK>        -------------->   BLOCK RECEIVED OK
  154.   <-------------     <EOT>         END OF FILE
  155.       <ACK>        -------------->    E-O-F UNDERSTOOD
  156.  
  157.  
  158. As you can see, it is through the responses to the sending
  159. computer that the receiver controls the link.
  160.  
  161.  
  162. Xmodem also makes provision for unusual circumstances by
  163. providing both time-out and cancellation mechanisms. The
  164. rules for time-outs, time periods which may elapse before a
  165. disruption in transmission occurs are as follows:
  166.  
  167.  
  168.  
  169.     1.    Waiting for SOH - 10 seconds, Resend last
  170.     acknowledgement on time-out.
  171.  
  172.  
  173.     2.    Waiting for other block characters - 1 second,
  174.     replace expected character with some pre-defined
  175.     value upon time-out.
  176.  
  177.  
  178.     3.    Waiting for a reply to a block - 10 seconds,
  179.     Resend last block upon time-out.
  180.  
  181.  
  182.  
  183.  
  184.  
  185.  
  186.  
  187.  
  188.  
  189.  
  190.  
  191.  
  192.  
  193.    CopyRight (c) 1987, 1988 Information Technology, Ltd.
  194.  
  195.  
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202.     LXM(tm) - LITECOMM (tm) XMODEM ENGINE for Microsoft
  203.            Datalight and Turbo C
  204.  
  205. The original protocol description also makes it possible for
  206. either the sender or receiver to cancel the transmission.
  207. This is of particular value when too many transmission
  208. errors occur, or, in rare cases, when the physical
  209. connection is broken. The threshold beyond which either side
  210. may request cancellation, although specified as 10 attempts
  211. in the original description of the protocol, has become
  212. somewhat arbitrary over time. The cancellation code, <CAN>
  213. or 0x10, may be sent by either the sender or receiver in
  214. place of the <SOH> or normal acknowledgment character
  215. respectively.
  216.  
  217.  
  218.  
  219. ENHANCEMENTS TO XMODEM
  220.  
  221.  
  222. Over the years, several significant enhancements have been
  223. made to the protocol as originally defined by Ward
  224. Christiansen. The intent of these enhancements have
  225. generally been to improve upon the error-handling capability
  226. of the protocol, and to make the protocol more amenable to
  227. some less time-efficient communications environments,
  228. particularly those presented by for-pay services such as
  229. CompuServe.
  230.  
  231.  
  232. To make the protocol more error-free, the checksum employed
  233. in the original design has been replaced by a 16 bit
  234. calculation, called a Cyclical Redundancy Check or CRC.
  235. Based upon a polynomial equation, the CRC method can be
  236. mathematically demonstrated to be sensitive to all but about
  237. .03 per cent of errors. This error detection rate, about
  238. 99.97 percent accurate, is far superior to the approximately
  239. 90 to 92 percent accuracy of the checksum approach. The
  240. overhead of an additional 8 bits per message seems to make
  241. this enhancement well worth while.
  242.  
  243.  
  244. The second enhancement seeks to improve communication over
  245. packet-switched networks, like those employed by CompuServe
  246. and other national services. Basically this enhancement
  247. introduces a relaxed time-out between characters in a block,
  248. allowing additional time before the protocol recognizes a
  249. time-out condition.
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.    CopyRight (c) 1987, 1988 Information Technology, Ltd.
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.     LXM(tm) - LITECOMM (tm) XMODEM ENGINE for Microsoft
  269.            Datalight and Turbo C
  270.  
  271. A third enhancement, variant of the original XModem protocol
  272. seeks to improve overall efficiency by expanding the block
  273. size from 128 characters to 1024 characters.  This variant,
  274. commonly call ymodem, reduces the number of times that an
  275. acknowledgment sequence must be sent, thereby increasing the
  276. efficiency of actual data transfer.
  277.  
  278.  
  279. The LXM XModem engine supports all of the enhancements
  280. mentioned above.
  281.  
  282.  
  283.  
  284.             THE LXM ENGINE
  285.  
  286.  
  287. OVERVIEW
  288.  
  289.  
  290. One of the reasons for the popularity of the XModem protocol
  291. over time is the simplicity of the implementation. Given a
  292. reasonable communications package upon which to build,
  293. developing a basic implementation of XModem is relatively
  294. simple, although under certain operating systems, such as
  295. the Unix family, the attempt of t